[% setvar title The Perl 6 Summary for the week ending 20030629 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030629'></a><h1>The Perl 6 Summary for the week ending 20030629</h1>
<p>Welcome to the third of my US tour Perl 6 summaries. Once again I'm
pleased to report that the denizens of the Perl 6 mailing lists
continue to make the life of a touring summarizer an easy one by not
posting all that much to the lists. So, I can sit here in my room at
the Shaker Inn in Enfield and marvel at the traffic noise outside,
wonder about the car next door with the New Hampshire plates reading
PERLFAN, and just generally appreciate the loveliness of the room.</p>
<p>But, while I'm doing that, I should start with perl6-internals</p>
<a name='Exceptions'></a><h2>Exceptions</h2>
<p>At the end of last week, Dan outlined his thoughts on how exception
handling will work in Parrot. This week, people talked about
it. Discussion revolved around how much information should be attached
to an exception and how/whether we should support resumable exceptions.</p>
<p><a href='http://groups.google.com/groups?threadm=a0521060abb1a415c7209@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='More on Continuation Passing'></a><h2>More on Continuation Passing</h2>
<p>Last week I said that &quot;I get the strong feeling that Leo T&ouml;tsch
isn't entirely happy with the new Continuation Passing Style&quot;. This
week Leo corrected me; I hadn't noticed that the speed issues had been
addressed by the latest changes to parrot (in fact the current CPS
implementation is faster than the old <code>invoke/ret</code> scheme.</p>
<p>Sean O'Rourke addressed Leo's problem with the Perl 6 Compiler tests
failing by saying that the compiler should really be ported to use CPS
rather than implementing a new variant of the Sub PMC that uses the
old scheme. Leo reckoned that such a port wasn't currently doable
because IMCC needed to be modified to use the CPS scheme, which would
also involve reworking the register allocator. Given Leo's prodigious
rate of implementation, this may have already happened.</p>
<p><a href='http://groups.google.com/groups?threadm=200306240712.h5O7Cb200882@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='IMCC/Parrot leak'></a><h2>IMCC/Parrot leak</h2>
<p>Clinton A. Pierce had reported a memory leak in Parrot, but tracked it
down to a situation where he was doing:</p>
<pre>    .arg 0
    call _foo</pre>
<p>And forgetting to take the 0 off the stack. However, even after he'd
fixed that, he had segfault issues, and posted a (largish) code
fragment that tweaked the bug.</p>
<p>It appears that Parrot wasn't throwing warnings when stacks get to
big, just failing silently. Leo added a check for too deeply nested
stacks, which at least avoids segfaulting on logic bugs.</p>
<p>Leo and Dan discussed other places where such limit checking should be
put in place. Dan also muttered something about turning stack chunks
into PMCs, allowing for the garbage collection of stack frames. Leo
also muttered about the proliferation of stack implementations in
Parrot (there are five) and thinks it should be possible to have one
general stack engine.</p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030623192413.0258eb20@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<a name='Making + a unary operator'></a><h2>Making <code>+</code> a unary operator</h2>
<p>Bernhard Schmalhofer found a problem with the Perl 6
implementation.</p>
<pre>    print +42, &quot;\n&quot;;</pre>
<p>printed '42', but omitted the carriage return. He fixed this by making
<code>+</code> into a unary operator as well as a binary operator and sent the
patch to the list, where it was applied. Good catch Bernhard.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-22765-59761.17.1648582488247@rt.perl.org' target='_blank'>groups.google.com</a></p>
<a name='ParrotIO File-Descriptors'></a><h2>ParrotIO File-Descriptors</h2>
<p>J&uuml;rgen B&ouml;mmels is in the process of porting the IO
subsystem from its current <code>mem_sys_alloc/free</code> based implementation
to the sunny, garbage collected, uplands of a PMC based
implementation. However, he's run into a problem; some of the
operations in <b><i>op.ops</i></b> use integer File Descriptors, grabbing
information from a table in the interpreter structure. This gets in
the way of garbage collection, since any integer could be a file
descriptor.</p>
<p>J&uuml;rgen proposed removing the integer file descriptors and
mandating that ParrotIO PMCs be the only way to access IO (including
the standard STDIN, STDOUT and STDERR). He proposed adding
<code>get_std[in|out|err]</code> ops to get at the standard streams.</p>
<p>Dan suggested that J&uuml;rgen Just Do It; the current IO system
being more than slightly hackish; essentially put in place until
something better came along.</p>
<p><a href='http://groups.google.com/groups?threadm=m2he6dgfaq.fsf@helium.physik.uni-kl.de' target='_blank'>groups.google.com</a></p>
<a name='Small Perl task for the interested'></a><h2>Small Perl task for the interested</h2>
<p>Want to get involved in the Parrot development process? Don't know
much about Virtual Machine design and implementation? Do know Perl?
Dan has a small but interesting task for you.</p>
<p>At present, Parrot gets built without any compiler level optimizations
turned on because files like <b><i>tsq.c</i></b> can't have any optimizations
turned on (<b><i>tsq.c</i></b> is the thread safe queue module, which is
&quot;annoyingly execution-order-dependent because it has to operate
safely as interrupt code potentially interrupting itself&quot;).</p>
<p>Dan would like a version of Configure.pl which can build a makefile
(or whatever build tool we end up using) with per-C-file compiler
flags, and it needs to be possible to override those flags, per file,
by the platform configuration module.</p>
<p>Interested? David Robins seems to be, and he asked whether the build
system had to be makefile based. Dan says not, but the really
important thing is that the resulting build script, or the config
system that generates the script be adequately
understandable/maintainable.</p>
<p><a href='http://groups.google.com/groups?threadm=a05210603bb20ad1ca7e1@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Scoping, .local and IMCC'></a><h2>Scoping, <code>.local</code> and IMCC</h2>
<p>Bugfinder General Clinton A Pierce is getting a headache trying to
understand <code>.local</code>. When he executes the following code</p>
<pre>    .local int f
    .sub _main
        .local int x
        .sub _foo1
            f=1
            x=2
            call _foo2
            end
        .end
        .sub _foo2
            print &quot;f is 1: &quot;
            print f
            print &quot;\n&quot;
            ret
        .end
    .end</pre>
<p>the output looks like:</p>
<pre>    f is 1: 2</pre>
<p>Which isn't quite what one would expect.</p>
<p>Leo explained what's going on; essentially it boils down to issues
with register allocation not being aware of <code>.local</code> scopes. He
recommended that Clint use either true globals or lexicals instead of
<code>.local</code>. Clint isn't so sure that this is a good idea, pointing out
that there are occasions when having lexically scoped names at the IMCC
level as well as at the level of lexical pads would be very
useful.</p>
<p>&quot;In my mind, when I saw: 1. <code>.local</code>, 2. automagical register
spillage in IMCC, and 3. nested compilation units I thought I'd found
Assembler Manna.&quot; -- Clint Pierce</p>
<p><a href='http://groups.google.com/groups?threadm=200306271506359.SM00172@localhost' target='_blank'>groups.google.com</a> -- Clint is puzzled</p>
<p><a href='http://groups.google.com/groups?threadm=3EFCC07A.3020809@nextra.at' target='_blank'>groups.google.com</a> -- Leo explains it all</p>
<a name='Tentative valclone patch'></a><h2>Tentative valclone patch</h2>
<p>Luke Palmer has been thinking about value and reference objects. He
wondered if there was any value in a <code>valclone</code> operator alongside
<code>set</code> and <code>clone</code> which would allow the target PMC to decide whether
to use <code>set</code> or <code>clone</code> semantics. He also offered a patch
implementing the operator if people thought it would be useful. Leo
T&ouml;tsch wasn't sure the new operator was necessary.</p>
<p>Klaas-jan Stol noted that he'd encountered problems with
reference/value confusion when he'd been working on his Lua compiler,
but he wondered if the problem couldn't be solved by having a general,
language independent &quot;argument&quot; PMC class. (I'm not sure I understood
what he meant by this so I'm hoping for an explanation with code
fragments).</p>
<p><a href='http://groups.google.com/groups?threadm=ygche6aj4il.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Events, exceptions and threads. Oh my!'></a><h2>Events, exceptions and threads. Oh my!</h2>
<p>There is a story that UK prime minister Harold MacMillan was asked by
a student what it was that concerned him most as Prime Minister. Mac
replied &quot;Events dear boy, events.&quot;</p>
<p>Leo T&ouml;tsch laid out his thoughts and ensuing questions about
Exceptions, events and threads, and how they played together. There
has been a small amount of discussion in response to this, but I think
everyone's currently thinking hard about the issue...</p>
<p><a href='http://groups.google.com/groups?threadm=3EFD623C.20604@nextra.at' target='_blank'>groups.google.com</a></p>
<a name='CPS and the call stack'></a><h2>CPS and the call stack</h2>
<p>Luke Palmer wondered if there would be a standard way of inspecting
the call stack (for debugging/<code>caller</code>/etc). (I think I'm going to
switch to using the phrase 'call chain' rather than call stack, as the
presence of continuations makes the call 'stack' look pretty
unstacklike...).</p>
<p>Leo and Dan both thought that this would be a high level language
issue rather than a Parrot issue, though Dan did note that there might
be useful things that Parrot could do to make such introspection
easier/possible.</p>
<p><a href='http://groups.google.com/groups?threadm=ygcllvmh1ya.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Continuation manipulation'></a><h2>Continuation manipulation</h2>
<p>Leo T&ouml;tsch has been thinking about occasions when one might need
to monkey with the internals of an existing continuation (he was
thinking about the 'warnings' state...) and proposed several
solutions. Dan favoured his new opcode, <code>updatecc</code> and thought it
would be good to be able to broaden the scope of what one could update
in a continuation/context. This scared Leo somewhat, but Dan came up
with some examples of where it might prove to be useful.</p>
<p><a href='http://groups.google.com/groups?threadm=3EFD8D74.2090506@nextra.at' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile in perl6-language'></a><h1>Meanwhile in perl6-language</h1>
<p>Almost nothing happened, there were all of 15 messages.</p>
<a name='Perl 6 Daydreams'></a><h2>Perl 6 Daydreams</h2>
<p>Miko O'Sullivan engaged in some summer daydreaming by asking what
everyone was looking forward to most from Perl 6. Miko himself is
looking forward to more Pure Perl modules; if Perl 6 delivers on its
performance promises then there are going to be more and more things
where implementing directly in Perl will be fast enough, and Perl is
so much easier to implement in than C...</p>
<p>Jonathan Scott Duff incurred Cozeny when he said that he's hoping that
by this time next year we'll have an 85% complete Perl 6 that will be
usable in production (by brave people). Simon Cozens noted that we
already have such a beast and it's called Perl 5. For some reason this
led to a new marketing slogan being proposed: Perl 6, the
reconstituted cheeseburger of programming languages. Somehow I don't
think that one's going to fly. (I just read this bit out to my wife
and she says that she really doesn't like the thought of a flying
reconstituted cheeseburger, so I think we'd best leave it at that.</p>
<p><a href='http://groups.google.com/groups?threadm=20030628024829.M17737@rescuemission.net' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>Tcha! I announce the retirement of Leon Brocard from his post as Perl
6 Summary Running Joke and put the right to choose the next joke up
for auction at YAPC. And what do you know, the winner of the auction
nominates Leon Brocard as the new running joke. So, settle in for
another year of desperate rationalizations for mentioning Leon in
these summaries. Who knows, maybe Leon's Parrot related workrate will
go up to such an extent that it'll be easy, but somehow I doubt it.</p>
<p>Thanks to, in chronological order, Adam Turoff and Lisa Wolfisch; Walt
Mankowski, Mark Jason and Laurie Dominus; Dave Adler; Dan and Karen
Sugalski; and Uri and Linda Guttman for being such fine hosts in
Washington, Philadelphia, New York, Hartford and Boston
respectively. Next time we do this, we will not be attempting to visit
quite so many cities on the Eastern Seaboard in such a short time. At
one point all we were seeing was Perl nerds and freeways in rapid
succession.</p>
<p>As ever, if you've appreciated this summary, please consider one or
more of the following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or a cute little iPod with a huge capacity to satisfy my technolust p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>.'></a>Send feedback, flames, money, photographic and writing commissions, or
a cute little iPod with a huge capacity to satisfy my technolust
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>.</li>
</ul>
</div>
